System and method for server-side optimization of data delivery on a distributed computer network

ABSTRACT

A system and method for the optimized storage and retrieval of video data at distributed sites calls for the deployment of “Smart Mirror” sites throughout a network, each of which maintains a copy of certain data managed by the system. User addresses are assigned to specific delivery sites based on an analysis of network performance with respect to each of the available delivery sites. Generalized network performance data is collected and stored to facilitate the selection of additional delivery sites and to ensure the preservation of improved performance in comparison to traditional networks.

This application is a continuation of U.S. Ser. No. 10/949,984, filedSep. 24, 2004, which application was a continuation of Ser. No.09/633,021, filed Aug. 4, 2000, now U.S. Pat. No. 6,799,221, which was acontinuation of U.S. Ser. No. 08/878,385, filed Jun. 18, 1997, now U.S.Pat. No. 6,112,239.

The invention relates to a system and method for distributed datastorage and retrieval, and more particularly, to a system and methodwhereby a user can acquire network performance information for a dynamicand distributed multipurpose network.

BACKGROUND OF THE INVENTION

The Internet is a loose network of connected computers spread throughoutthe world. A message can be sent from any computer on the Internet toany other by specifying a destination address and passing the messagefrom computer to computer via a series of “hops.” Each computer, router,or “node” on the Internet has a unique Internet address. When anintermediate computer or router receives a message in transit, thecomputer checks the intended destination of the message and passes italong accordingly.

The Internet is growing, in terms of both size and sophistication, at arapid rate. In the past, most users of the Internet were academic,research, or institutional users; the Internet was primarily used atthat time to transmit and receive electronic mail and network news andto allow transfer of computer files. However, since the introduction ofthe World Wide Web (also known as the “Web”, or the “WWW”) several yearsago, the Internet has begun to host increasing amounts of other types ofdata of general interest, namely representations of images, articles,etc.

The Web protocol and language establish a graphical means to navigatethe expanses of the Internet. “Web pages,” often consisting primarily oftext and graphical material, are stored on numerous computers, known as“Web servers,” throughout the Internet. A software program known as a“browser” can be used to access and view Web pages across the Internetby specifying the location (i.e. Internet address) of the desired Webpage. When a Web page is accessed, its information is transmitted fromthe remote computer (server or delivery site), wherever in the world itmay be located, across the Internet, to the user.

In recent times, the Web has begun to host highly sophisticated types ofmultimedia content, such as audio and video data, and computer software.Compared to first generation Web content, namely text and still images,audio clips, video clips, and software programs have extremely highstorage and bandwidth requirements.

At present, it is difficult, if not impossible, to provide sustainedhigh-speed transmission of large audio/video files over a multi-nodelink on the Internet. Because the data is often transferred from afar,many factors can cause the delay or even loss of parts or all of atransmission. It is generally not critical if a user experiences minordelays in receiving small graphic or text files. However, it isrecognized that real-time data such as video has very specific andstringent timing requirements for data transfer and display.

Unfortunately, the present design of traditional Internet-like datanetworks is based on the principle that delays and significant datatransmission rate variations are acceptable for ordinary data (e.g. textand still images). Consequently, because of the high value of permittingaccess to text and graphical information from locations around theworld, such transmission defects are considered acceptable, and the basecapacity of the Internet is somewhat “oversubscribed” to reduce datatransmission costs. In other words, the timeliness of network datatransmission has been significantly compromised in order to renderrelatively insignificant the aggregate cost of long distancecommunication connections.

In order to successfully transfer audio-video data across amessage-oriented network such as the Internet, for any more than a fewusers, network resources should be committed in a manner facilitatingtimeliness of transmittal. A system using committed network resourcesgenerally cannot take advantage of the existing pricing scheme of sharednetworks like the Internet, since it cannot participate in the sharingof network resources on a data packet by data packet basis. Video datamust be transmitted to the exclusion of lower-priority data.Transmission costs thus become significant, especially when theconnection is “long distance” or when the connection is continued overan extended period of time.

Another consequence of the timeliness vs. cost compromise discussedabove has been the seemingly indiscriminate topographical design of thenetwork. Since delays and throughput variations have traditionally beenexcused in favor of low cost, the configuration of the Internetinfrastructure has also been driven by cost considerations. Accordingly,the interconnection efficiency of the network has rarely beenconsidered. The rapid growth of real time data is changing thisrequirement.

It is recognized that inadequate data transfer performance oftime-sensitive data on the Internet is typically caused by four factors:packet loss, excessive server utilization, the relatively low capacityof the network infrastructure, and inherent delays in the networkhardware. Packet loss, in particular, is caused by inadequateinfrastructure and lack of robustness in routing. The inherent delaysare believed to be caused by, among other things, the lack of flowcontrol between adjacent nodes in a multiple-node path on the Internet.

Unlike smaller text and graphic files, relatively large video files cantake several minutes (or more) of “streaming,” or constant data flow.Consequently, the usual network performance problems are exacerbated.Network bandwidth, or the data-carrying capacity of a particularnetwork, is limited. Thus, packet loss and delays increase. Longdelivery times consume a large amount of server capacity for a longtime, decreasing the resources available to other users. Accordingly,because the network infrastructure becomes increasingly congested,packet loss and delays continue to increase, transmission times rise,and server load increases further.

This pattern exemplifies a “downward spiral” of network performance,which can be driven by the attempted transmission of large data filessuch as video clips. As long as network traffic remains within thelimits imposed by network bandwidth, network performance will remainacceptable. However, whenever peak network loads exceed capacity, thedownward spiral described above will begin, causing increasing periodsof poor network performance.

As discussed above, a browser program can be used to access and view Webpages across the Internet by specifying the location (i.e. Internetaddress) of the desired Web page, or more commonly, by “hotlinking” toWeb pages. Common browsers are Lynx, NCSA Mosaic, Netscape Navigator,and Microsoft Internet Explorer. The desired Web page is specified by auniform resource locator (“URL”), indicating the precise location of thefile using the syntax “http://internet.address/directory/filename.html”.

Web pages are generally described, in terms of layout and content, byway of a language known as “HTML” (HyperText Markup Language). Anyparticular computer linked to the Internet can store one or more Webpages, i.e. computer files in HTML format, for access by users.

Hotlinking from one HTML Web page to another is accomplished as follows.The user first accesses a Web page having a known address, often on thecomputer located at the user's ISP (Internet Service Provider). The ISPis the organization providing Internet connectivity to the user. ThatWeb page can contain, in addition to textual and visual data specifiedin HTML format, “links,” or embedded information (in the form of URLs)pointing to the Internet addresses of other Web pages, often on othercomputers throughout the Internet. The user, by selecting a link (oftenby pointing and clicking with a mouse), can then access other Web pages,which can in turn contain further data and/or additional links.

Various extensions to HTML, such as Netscape's EMBED tag, allowreferences to other data to be embedded into Web pages. Some browsersare not capable of handling data other than text and images. Otherbrowsers can handle the data in various ways. NCSA Mosaic, for example,handles references to unknown types of data by allowing the data to bedownloaded to the user's computer, and then optionally invoking anexternal program to view or manipulate the data. Recent releases ofNetscape Navigator and Microsoft Internet Explorer take the concept onestep further: a browser extension, or “plug-in,” can be automaticallyinvoked to handle the data as it is received from the remote Web page.Other means, such as network program “applets” written in the Javalanguage (or a similar language), can be used to extend thefunctionality of the browser environment or network.

Digital multimedia data can have extremely high storage and bandwidthrequirements. In particular, video files can be very large, fromapproximately 10 megabytes to 10 gigabytes. In order to play video filesat speeds approaching their recorded rate at a user's terminal, thefiles have to be delivered at a fast, constant speed. Too slow, and theimage plays back slower than originally recorded. If the speed isuneven, then the video appears jerky, like an old-time movie.

The network design compromises discussed above generally adverselyimpact the transmission of audio and video data across the Internet.While a user using a browser to “surf” the Web might not notice minordelays and transmission rate variations while retrieving text and stillimages, such defects become apparent and significant when real-timeaudio and video information is accessed.

In an attempt to solve these problems, Internet content providerssometimes spread popular content around the Internet on various serversor delivery sites known as “mirror sites.” Each mirror site containsinformation that is essentially identical to that of the original site.For example, if a popular Web site is located in New York, mirror sitesmight be located in Los Angeles, London, and Tokyo. Accordingly, if aEuropean user is having difficulty accessing the original New York site,he can hotlink to the mirror site that is geographically closest, i.e.London. However, mirror sites have several disadvantages. For example,mirror sites may be widely distributed geographically, but may not beefficiently distributed on the network in terms of actual usage, networktraffic, etc. Thus, New York and Los Angeles mirror sites might both beconnected to the same national Internet service provider's network,meaning that difficulty in accessing one of the sites might also affectthe other.

Furthermore, mirror sites might not be optimally placed to reduce loadon each server. Although an “educated guess” might be made as to where amirror site should be located, actual usage patterns might differ.Furthermore, there is no guarantee of enhanced performance. Thebandwidth of the mirror site might be lower than that of the originalsite, or it might be overloaded for other reasons.

Moreover, mirror sites are often hosted on a voluntary basis. If a Website is extremely popular, and a service provider determines that thesubject matter might be of interest to its subscribers, that serviceprovider might agree to host a mirror site of the original Web site.Such an arrangement would be attractive to host of the mirror sitebecause people would be drawn to the mirror site, and might hotlink toother content hosted there. On the other hand, such voluntary alliancestypically are not reliable and might be severed at any time.

In essence, a mirror site offers a secondary source for data, which mayor may not be available, and which may improve user convenience, butwhich does not address network bandwidth or efficiency. A mirror sitedoes not account for performance characteristics of the network, noridentify available bandwidth which could be used to efficiently transmitvideo data while still taking advantage of the existing low-cost pricingschemes such as those on the Internet.

Currently, there is no guidance in selecting optimal locations fordelivery sites, nor is there a known method permitting a user todetermine which mirror site to connect to that will ensure optimumperformance. In fact, the use of a traditional mirror site is voluntary.Typically, a user will try to access the original site (or a knownmirror site), and will switch to another mirror site only if performanceis found to be insufficient after one or more attempts. This approach isan inefficient utilization of network resources. Clearly, mirror sitesare not an optimum solution to the problem of overloaded Web sites. Aprincipal reason for this, among others, is the failure to considernetwork performance.

Network analysis, particularly the performance of specific paths andlinks over the Internet, is well known and developed. For example, the“ping” program allows a computer connected to the Internet to determinewhether a remote host is accessible. However, the ping program uses alow-priority network protocol known as the ICMP protocol, andaccordingly does not provide meaningful performance analysisinformation. The “traceroute” program follows the transmission of amessage from a computer to a remote host, tracking delays along eachlink, and determining the path taken by the message. The tracerouteapplication can be used to map the flow of data. However, it lacks theability to provide meaningful performance analysis information.Traceroute only provides route information for a message propagating inone direction, and only for one instant in time.

Moreover, only the connectivity characteristics of paths leading to andfrom the single computer running the tests are typically determined;expanding the scope of testing is possible but logisticallyimpracticable, since the Internet is so large.

Traditional network analysis techniques such as the “ping” and“traceroute” programs offer a view of network connectivity but providelittle understanding of what performance can be expected from providersand mirror sites across the Internet. Therefore, only “guesses” can bemade as to where delivery or mirror sites should be located or whichmirror sites should be used to optimize performance.

Accordingly, a need exists for a method of determining overall networkperformance. A further need exists for a system applying that method toenable content providers to dynamically locate data delivery or mirrorsites at optimum network locations, and to allow users to select optimummirror sites from which to receive data.

SUMMARY OF THE INVENTION

The invention is directed to a system and method for the optimizeddistribution of Web content to sites located around the Internet. Anintelligent mirroring scheme, called here “Smart Mirroring,” is used todetermine the need for and distribution of mirror sites and to directuser requests for certain Web content to an optimum mirror site.

A number of “smart” delivery or mirror sites are used to distributepopular Web content to various parts of the Internet. A comprehensivescheme of network analysis, based on tests performed by a large numberof users, is used to interactively determine the preferred locations forthe sites, and to determine the optimum sites to be used by eachindividual user.

Accordingly, because each individual user is routed to a Smart Mirror ordelivery site that provides improved performance, overall networkcongestion is reduced. In most cases, the improved server is locatedelectronically close to a user in order to decrease the number ofnetwork connections over which data must travel, thereby reducing packetloss and delay.

Furthermore, network analysis results allow message traffic to be routedaway from those delivery sites and network regions that are alreadyoverloaded, and toward underutilized servers and networks. This resultsin an improvement in throughput as seen by each user, and will therebyincrease the appeal of the content offered by content providers usingthe system. Content providers are able to reach a larger number of usersacross the Internet without suffering significant decreases inperformance.

A system according to the invention begins with an original Web site andat least one additional delivery (or mirror) site. Each user desiring touse the system will be provided, in a preferred embodiment, withsoftware which includes a configuration utility and a client program.The configuration utility is used first to determine which deliverysites provide improved performance for that particular user.

In one embodiment of the invention, the configuration utility firstdownloads a “delivery site file” from a service provider. This deliverysite file contains a list of available delivery sites and a list ofnetwork tests to be run. The types of tests and frequency of testing tobe performed may be specified in the delivery site file, as dependent onthe number of users testing the network and the estimated drain onnetwork or delivery system capacity.

The configuration utility will run a subset of the tests specified inthe delivery site file. The test results show which delivery sites yieldimproved performance for the user, and also contain information onvarious generalized network capabilities from the standpoint of the userrunning the tests. The network test results and the identity of thechosen delivery site will be sent (via e-mail in one possibleconfiguration) back to the delivery service provider for incorporationinto the service provider's database.

The delivery site chosen by the configuration utility is then used bythat user for the retrieval of all content managed by the deliverysystem service provider. Consequently, when the user is browsing Webcontent, and finds a particular item, e.g. a video clip, that is managedby the service provider's delivery system, the client software willautomatically retrieve it from the specified “Smart Mirror” deliverysite. Site preferences and default sites can be updated periodically onrequest, at specified times, or in response to changes in network loadand traffic.

Moreover, because the configuration utility of the invention isperforming various network tests and providing the test results to theservice provider, valuable data on system and network performance isavailable. Such data provides information on which “Smart Mirror”delivery sites are performing effectively and which are not, which SmartMirror delivery sites are overloaded, and what portions of the Internetmight benefit from the addition of more delivery sites or capacity. Suchdata also makes it possible to perform such sophisticated networkanalysis as end-to-end performance measurements, workloadcharacterization, route stability, and outage metrics.

In an embodiment of the invention, the mirror service provider uses thenetwork performance data provided by the end users to derive a look-uptable which correlates Internet IP addresses with “electronically close”delivery sites. When a user is browsing web pages and requests a file,e.g. an advertising banner or video clip that is managed by the serviceprovider's delivery system, the service provider can map the user's IPaddress to the look-up table and determine which delivery sites are“electronically close” to the user. The service provider can thenprovide the user's configuration utility or client program with a singledelivery site address or a list of delivery site addresses for theseservers. In the latter case, the user terminal acts as a router makingthe final delivery site selection.

In general, an improved delivery site for a particular user can bepredicted in advance by analyzing aggregate network performance datacollected from network tests previously performed by a group of users.Thus, delivery site selection can occur on-the-fly each time the userrequests a file managed by the mirror service provider's deliverysystem. From the perspective of the user, the selection of the deliverysite happens automatically and transparently such that there appears tobe no delay between selecting a file from a web page and having the filedelivered to the user's terminal. The look-up list maintained by theservice provider is constantly updated to reflect changes in networkperformance, making it possible for the service provider to effectivelyload-balance network traffic.

Thus, from an engineering standpoint, the mirror service provider cancontinue to ensure that improved performance is being provided. From amarketing perspective, content providers can be told where to locateSmart Mirror or delivery sites for improved performance, and what ISPprovides improved delivery.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an illustrative network topology of asystem according to the invention, including multiple users and multiplecontent providers;

FIG. 2 is a flowchart describing the operation of the configurationutility used in a system according to the invention;

FIG. 3 is a flowchart describing the operation of a client program usedin a system according to the invention; and

FIG. 4 is a flowchart illustrating how site selection is performed in anembodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

The invention is described below, with reference to detailedillustrative embodiments. It will be apparent that the invention can beembodied in a wide variety of forms, some of which may be quitedifferent from those of the disclosed embodiments. Consequently, thespecific structural and functional details disclosed herein are merelyrepresentative and do not limit the scope of the invention.

Referring initially to FIG. 1, the Internet 10, which is intended to berepresentative of wide-area communications networks in general, isdepicted as a “cloud.” The Internet is known to be an interconnectednetwork of a large number of computers. Although Internet-connectedcomputers that are “geographically” near each other can be“electronically” near each other on the Internet, such is not usuallythe case. However, one computer connected to the Internet cancommunicate with any other computer connected to the Internet; themessage will most likely travel over a path comprising a sequence oflinks, or “hops,” between computers that are directly connected to eachother.

A first user terminal 12 is also depicted in FIG. 1. The first userterminal 12 is connected to an Internet service provider (ISP) 14, whichis typically just a computer, router, or terminal server connected tothe Internet 10. An ISP 14 can host additional user terminals, such as asecond user terminal 16. Other ISPs, such as a second ISP 18, are alsoconnected to the Internet 10. A third user terminal 20 is shownconnected to the second ISP 18. Only three user terminals are shown;however, it should be recognized that the number of concurrent users ofthe invention is unlimited, subject to the operational details set forthbelow.

As is known in the art, content providers are also connected to theInternet 10. A first content provider 22 might provide a certain kind ofcontent, for example sports scores and highlights. A second contentprovider 24 might provide a different kind of content, for examplebusiness news.

Traditionally, if a user (such as the one using the first user terminal12) wished to access the content provided by the first content provider22, the terminal 12 would query the first content provider 22 directly.A request message would propagate from the terminal 12, across theInternet 10, to the content provider 22. The content provider 22 wouldsend the desired data across the Internet 10 back to the terminal 12.

Several delivery, or “mirror” sites are shown connected to the Internet10 in FIG. 1. A first delivery site 26 might be located a small numberof “hops” from the first user terminal 12. A second delivery site 28might be located further away from the first user terminal 12, but closeto the third user terminal 20. A third delivery site 30 might be asclose to the third user terminal 20 as the second delivery site 28 is.As previously noted, a user and a provider or delivery site that are“geographically” near each other might not be “electronically” near eachother on the Internet. By decreasing the “electronic” distance betweenthe user and the provider or delivery site, the number of networkconnections and routers over which data must travel can be decreased.

As discussed above, the Smart Mirroring system acts to improve networkperformance by decreasing the incidence of the foregoing networkproblems. Packet loss and delay problems are generally decreased byreducing the number of network connections over which data must travel,although in some cases, the network testing procedure of the inventionshows that some longer paths provide better throughput than some shorterpaths. Very little packet loss, and essentially no delay, occurs innetwork cable; it typically is caused by overloaded network storage androuting devices. Because the Smart Mirror sites of the invention arelocated electronically near each user, packet losses and delays arereduced. The problem of excessive server utilization is reduced becausemultiple delivery sites share the load that typically would have beenhandled by a single server. The relatively low capacity of the networkinfrastructure becomes less of a problem, because data retrieved fromparallel delivery sites in different locations generally need not travelover the same network links.

For the purposes of describing this invention, a delivery site is a“node” on the network which may store data or other files, such assoftware code, for delivery. The term can also include a site which isresponsible for data delivery, including mirror sites, contentproviders, and servers for broadcast video streams or Web sites.

In the system, a mirror service provider (MSP) 32 is connected to theInternet 10. The MSP 32, which exercises a management function over thedistribution of delivery sites 26, 28, and 30, and over the allocationof requests to the original and delivery sites from user terminals 12,16, and 20, includes a database capable of transmitting and receivingdata over the Internet 10.

This management function is facilitated by the use of a configurationutility 34 and a client program 36 run within a storage medium (i.e.random access memory) on the user terminal 12. Although theconfiguration utility 34 and the client program 36 are shown in FIG. 1as a part of only the first user terminal 12, it should be recognizedthat any user terminal, such as terminals 16 and 20, participating inthe system will use such software. A user desiring to participate in thesystem can obtain the software comprising the configuration utility 34and client program 36 directly from the MSP 32, or through traditionalretail or other channels (such as being part of the browser or operatingsystem of the computer). It should be noted that the functions performedby the configuration utility 34 in the described embodiment of theinvention can be integrated into general Internet application software,such as a browser or other network application; a stand-alone program isnot necessary.

In a preferred embodiment, the configuration utility 34 must be run bythe user, either by command or automatically, before the user terminal12 will have access to the system. The operation of the configurationutility 34 is shown in detail in FIG. 2.

The configuration utility 34, when first run on the user terminal 12,retrieves a delivery site file (step 40) from the MSP 32 (FIG. 1). Ifthe user already has a delivery site file (e.g., it was received withthe configuration utility 34), and that delivery site file issufficiently new, the delivery site file can be retrieved from the localhard disk of the user terminal 12. This delivery site file contains alist of all available delivery sites (such as delivery sites 26, 28, and30) and a list of network tests to be run at the user terminal 12. Inthe context of the invention, there can be as few as two delivery sites,or if the number of users justifies it, as many as several thousand. Thenumber of sites in principal is unlimited, with each available deliverysite represented in the delivery site file.

The delivery site file is generated by the database from within theMSP's computer system. The database application uses information aboutthe user to dynamically determine the optimum tests to run.Consequently, the delivery site file need not contain entries for everydelivery site in existence; the list can be tailored to include onlythose sites which appear appropriate or feasible.

Initially, the magnitude of run-time variation in test configurationsfor the delivery system users is low; that is, the first group of usersall run essentially the same tests. As the delivery service grows,however, the intensity of each user's testing is reduced in order tocompensate for the increased magnitude of testing network-wide. Thescope of testing and the number of delivery sites tested both can benarrowed to further reduce the aggregate load of network testing.

In one embodiment, the delivery site file will have a format generallyas follows:

1. File Revision Number and Message. The file includes this field todetermine whether a new version of the configuration utility 34 isavailable. If the revision number in the delivery site file is higherthan the version number for the configuration utility, configuration isnot allowed. Instead, the user would be prompted to acquire a newerversion of the configuration utility 34. File revision verification asdescribed herein ensures that the most up-to-date delivery siteselection algorithms are applied to the test data generated by theconfiguration utility 34.

2. A list of available Smart Mirror delivery sites.

For each available delivery site, the following information is provided:

a. Host name. In the known Internet format of “www.server.com.”

b. IP Address. A numerical Internet address in the known format. Theaddress is presently a 32-bit number of the form w.x.y.z., where w, x,y, and z are each in the range of 0 to 255.

c. Alternate Name. An informal name such as “The First Mirror Site.”

d. A list of tests to be executed. For each test, the followinginformation is provided:

i. Test ID. Each type of test has a unique identifier known to theconfiguration utility 34.

ii. Weighting factor. Each test will be weighted by a specifiedpercentage.

iii. Frequency. Each test is not necessarily run every time. This fieldspecifies a probability, determining how often a particular test will berun.

iv. Additional Information (optional).

For certain tests, additional information may be needed.

e. Site Preference Level. Each site can be given a weighting, orpreference level, between, for example, 1 and 100. As discussed below,aggregate data in the MSP's database is used to perform network usageanalysis not possible with only the single user's instantaneous end toend testing. The weighting factor provided here is used to incorporatethe test results received from the service provider's database. Thisweighting factor is also used to limit assignment of new users to adelivery site once a predetermined maximum usage level has been reached.

f. Test Site Flag. If this flag is enabled, the foregoing tests will berun, but the site will not be assigned as a delivery site even if ityields the best performance.

g. Content Provider Groups. Each site can belong to one or more contentprovider groups, thereby mirroring only certain content. If a user isnot interested in the types of data hosted by a particular deliverysite, then it does not need to be tested.

The configuration utility 34 then queries the user (step 42) for variousitems of information needed in the configuration process, for example,the user's name, e-mail address, password, modem speed, and informationrelated to access control (e.g. what levels of various attributes areviewable by the user). The access control mechanism will be discussed infurther detail below. In one embodiment of the invention, theinformation received from the user is encrypted and stored in aconfiguration file on the user terminal 12.

The configuration utility 34 then determines whether the user terminal12 is connected to the Internet (step 42). If not, it will initiate aconnection (step 44) or prompt the user to do so.

A series of network tests is then performed (step 46). One or more testscan be performed for each available site listed in the delivery sitefile; not all sites in the file need to be tested.

The following test types are presently considered to provide usefuldata:

1. Ping. Provides information on whether a remote server is reachable,and if so, how long it takes for a low-priority message to travel roundtrip from the user terminal 12 to the remote server and back. Ping is asimple test useful in deciding whether a site is available for furtherevaluation. Excessive times returned by the ping application can be usedto eliminate delivery systems which are far too “slow” for effectiveinformation delivery. This test is used by the terminal to reduce thenumber of delivery sites tested.

2. Traceroute. Provides information on what route is taken by a messagefrom the user terminal 12 to a remote server, including what systems areused along the way, and how long each hop takes. Traceroute is used bythe configuration program 34 to document the path of informationtransmission. Several traces with differing results might indicate thatthe stability of the route from a particular user to a specific serveris not acceptable. Previously aggregated data on particular routes, fromthe service provider's system database, may also influence the decisionto choose a particular delivery site for a specific user. Routestability is the primary consideration.

3. Reverse Traceroute. Provides information on what route is taken by amessage from a remote server to the user terminal, including whatsystems are used along the way, and how long each hop takes. ReverseTraceroute is used by the configuration program to document the path ofinformation receipt. Several traces with differing results mightindicate that the stability of the route from a particular server to aspecific user is not acceptable. Previously aggregated data onparticular routes, from the service provider's system database, may alsoinfluence the decision to choose a particular delivery site for aspecific user. Again, route stability is the primary consideration.

4. Dynamic Traceroute. Similar to traceroute or reverse traceroute, butbetween any specified pair of computers on the Internet. DynamicTraceroute is used by the configuration program to document a path ofinformation transmission. Several traces with differing results mightindicate that the stability of the route between two network locationsis not acceptable. Previously aggregated data on particular routes, fromthe service provider's system database, may also influence the decisionto choose a particular delivery site for a specific user. As above,route stability is the primary consideration.

5. Name Server Resolution Delay. If the numeric Internet address isunspecified, a name server lookup is performed to determine what numericaddress corresponds to the desired host name. This process can take asubstantial amount of time.

6. Throughput. A sample file is downloaded, or partially downloaded,from the remote server to determine the actual throughput in bytes persecond.

7. Throughput variation. A sample file is downloaded, or partiallydownloaded, from the remote server to determine if the throughput isrelatively constant or fluctuating.

8. Error rate. A sample file is downloaded, or partially downloaded,from the remote server to determine if the transmission is subject totransmission errors. This information is obtained by counting the numberof error message packets returned to the user, thereby learning of theerror rate from the user to the server, and by tracking the number ofbytes received as a fraction of the number of bytes transferred, therebylearning of the error rate from the server to the user.

9. Packet Fragmentation. A sample file is downloaded, or partiallydownloaded, from the remote server to determine it the transmission issubject to fragmentation or out-of-order packet reception.

10. Capacity Query. If the remote server is so enabled, theconfiguration utility 34 queries the server to determine itstransmission capacity and its average load. This information iscollected via the Simple Network Management Protocol (“SNMP”), which issupported by nearly all Internet servers.

11. Macroscopic Network Analysis. The data accumulated by the MSPdatabase offers a global view of network behavior. This informationpermits the Smart Mirror system user to have a historical view of theperformance of the available delivery sites. The accumulated data ismanipulated by the delivery system database to analyze networkperformance, in order to emphasize usage in high-capacity areas of thenetwork, while deemphasizing usage in areas already experiencingdiminished performance.

Information on how each of the foregoing tests are performed is wellknown in the art of network analysis. See, e.g., Bob Quinn and DaveShute, Windows Sockets Network Programming (Addison-Wesley 1996). In oneembodiment of the invention, testing is accomplished by performing a“ping” test to verify whether a server is reachable, a series of small(e.g. 20K) downloads, a series of large (e.g. 200K) downloads, and“traceroute” and “reverse traceroute” tests to document delivery paths.

The traceroute information is used by the MSP 32 to correlate test datato information in its database; in that way, particularly bad networklinks and servers can be identified. Such information is provided in thedelivery site file discussed above; if a particular link or server isknown to be unreliable, based on information obtained from other users,an individual user can be routed away from it, even if a single testgives good results.

The short downloads are used to determine server capacity. The nameserver resolution delay can be determined by such a test, as well as thetime it takes a server to begin sending data. The later result isstrongly related to server load, capacity, and performance.

The long downloads allow the configuration utility 34 to determine howpacket loss, network congestion, and server utilization affect filedelivery. It is not ideal to determine which of the foregoing factors iscausing decreased performance based on test results from a single user.However, such results in the aggregate, as stored in the databasemaintained by the MSP 32, indicate the root causes.

It should be noted that some of the test results may be used inconjunction with other test results. For example, the load on a deliverysite as determined through a capacity query can be divided by theresults of a throughput test to derive an average expected downloadtime, given the load characteristics of the server.

After all specified tests are run, the results are collected andprocessed (step 48). It is possible that certain tests were not able tobe successfully performed; in such cases, the results should indicate anappropriate worst-case value (e.g. zero throughput or extremely highdelay).

It is important to note that not all possible tests will be performedeach time the configuration utility 34 is run. When a large number ofusers are using the system, a substantial drain on server and networkcapacity would be caused by the testing procedure alone, increasing thedownward spiral of network performance previously discussed.

As noted above, a test frequency number is stored in the delivery sitefile for the purpose of dynamically controlling the number of usersperforming a test. The testing performed by the configuration utility 34is performed to achieve statistical confidence in deciding whichdelivery site is best suited for data delivery to a particular user.Statistical confidence is obtained by testing a small sample of userssufficiently well and using that data to influence the choice of adelivery site, or by having a large number of users each “lightly” testseveral available sites and using that data in the aggregate.

Accordingly, when the system is used initially, a relatively smallnumber of users are “enrolled” in the system. The delivery site filemaintained by the MSP 32 reflects those conditions, and requires eachuser to test the network (through the configuration utility 34)relatively heavily. As the number of users increases, the delivery sitefile is modified to decrease the tests performed by each user. By thetime a very large number of users are using the system, theconfiguration utility 34 may predominantly test for delivery sitereachability (via a “ping”-type test, as discussed above), and relyprimarily on test data provided by other users and stored in thedatabase maintained by the MSP 32. However, even when many users aretesting the system, a small number of users (e.g. one in 5,000) may beselected to run a comprehensive set of tests.

Preferably, testing should not contribute more than approximately 5% oftotal server load. One way to reach this goal is to lightly test a largenumber of servers, yielding a group of delivery sites having adequateperformance. This group of delivery sites can then be used in rotationto retrieve data. Information on multimedia clip actual download timesfor each of the delivery sites in the group is accumulated as discussedbelow, and further information on delivery site performance can then befurnished to the MSP 32 transparently, without the need for furtheroutright testing.

Accordingly, on the basis of the collected test results, and oninformation provided in the delivery site file by the MSP 32, theconfiguration utility 34 determines which delivery site, or group ofdelivery sites, is best for the user terminal 12 (step 50). Thisdetermination can be made numerically by weighting the various testsperformed and comparing the score for each site.

In a presently preferred embodiment, for use in a low-trafficenvironment with a relatively small number of delivery sites and users,the configuration utility 34 relies primarily on ping and throughputtests for each available delivery site. An initial ping test isperformed to determine if a delivery site is reachable. Short and longdownloads are performed in the throughput tests to determine the maximumand minimum throughputs from the delivery site, and to determine whetherthroughput variation is small enough to accommodate the transmission ofvideo data. Accordingly, those tests are all given high weights. Othertests, such as traceroute, can be performed, and the results reported tothe MSP 32, without playing a role in the choice of delivery sites (suchother tests can be given weights of zero, or nearly zero, for example).As the size of the system increases, and additional delivery sites andusers are enrolled, the site selection formula can be altered, bychanging the delivery site file contents, to reflect changing networkconditions.

In one embodiment of the invention, a proprietary graphical interface isprovided so that the location of the user and the locations (bothgeographic and electronic) of each site tested can be displayed on amonitor connected to the user terminal 12, allowing a visual indicationof the relative distances between sites. In one embodiment, the displayis shown in the form of a “radar screen,” upon which the user terminal12 and delivery sites are displayed as “blips” superimposed over a mapof the pertinent geographical region. In order to encourage the user touse the application and to offer more network-wide data, the userinterface can allow the user to enter an “ad-hoc” test site foradditional performance testing. In this case, the configuration utilitywill test either the default Web page file (e.g., “index.html”) or aspecific file requested by the user. Analysis results from theuser-selected site are adjusted so that reasonable comparisons can bemade with results from other sites.

It should be noted that multiple sets of delivery sites can bemaintained by the invention, to accommodate several groups of contentproviders. Each content provider might be mirrored only at certainsites. Accordingly, for each content provider having a unique set ofdelivery sites, a primary delivery site is selected by the configurationutility 34. To accomplish this, the foregoing tests can be run once, andthen, in one embodiment, a numerical weighting can be applied to eachappropriate set of delivery sites. A plurality of Smart Mirror sites isselected, one for each content provider group. The content providergroups is specified in the delivery site file; each possible deliverysite is identified as belonging to one or more content provider groups.When content provider groups are used, there can be as few as twogroups; the maximum number is essentially unlimited.

It should also be noted that a prioritized ranking of delivery sites canalso be generated and maintained. If this is done, failure of theprimary Smart Mirror site to respond will allow the system to fall backto the next-highest ranked Smart Mirror site.

After a Smart Mirror site is selected, certain data will be sent to theMSP 32 (step 52) via e-mail or other Internet electronic protocol. Theinformation received by querying the user, the identity of the selectedSmart Mirror site, and all raw test data and results, including the timeand date at which each test was run, is compiled into a text file (whichis encrypted in one embodiment). Upon receipt by the MSP 32, the data isstored in a database for use in managing and analyzing the system.

Finally, the configuration utility 34 saves the identity of the selectedSmart Mirror site for each set of delivery sites, or the prioritizedlist, to the (encrypted) configuration file (step 54). The configurationutility may also save information on relative performance for eachtested delivery site. The client program 36 uses the encryptedconfiguration file to download data files (video clips or other content)from the appropriate Smart Mirror site.

It should be noted that in the operation of the system, the MSP 32performs certain functions. The MSP 32 maintains the delivery site list,adding and deleting sites as necessary. The MSP 32 also maintains thedatabase of network performance, containing information received viae-mail or other means from users running the configuration utility 34.As large amounts of data are received from numerous users, the databasecan provide valuable information on the performance and othercharacteristics of the Internet and portions thereof. Various dataprocessing techniques are known to derive such information.

The locations of the delivery sites used with the invention areultimately determined by a number of factors, including marketingconsiderations and cost/benefit analyses. However, the data stored inthe MSP's database can confirm the utility of placing a delivery site ata given location on the Internet or other network. In one embodiment,servers are located on each major backbone (portion of the Internetmaintained by a single corporation) and on other Internet lines servinglarge numbers of users, such as the major lines operated by the RegionalBell Operating Companies (“RBOCs”). In certain networks serving largenumbers of users or having heavy video delivery traffic, servers can beplaced at major Points of Presence (“POPs”) for the network to ensurethat each user has access to a fast server.

Once the configuration utility 34 has been run, the user can use thesystem to enable and facilitate the receipt of data files, specificallyvideo clips, audio clips, software programs, and other content.

As time passes and the usage patterns of a user's region of the Internetchange, the user might become dissatisfied with the performance of theSmart Mirror site associated with his user terminal 12. If this happens,the user may re-run the configuration utility 34. By that time,additional delivery sites might have been placed into service, or adifferent pre-existing site might perform better than the one previouslyassigned. Furthermore, if the player program 36 determines that theselected Smart Mirror site is not performing adequately (e.g., it hasfailed three times out of ten attempts), the player program 36 canprompt the user to re-run the configuration utility 34. In otherembodiment of the invention the testing and mirror assignment is runautomatically with each request for a file on the Smart Mirror serviceor at some intermittent times such as after every other, every third,every tenth or every one hundredth request.

In one embodiment of the invention, the Smart Mirror system is used tolocate a delivery site from which to download a video or audio clip(“clip”) referenced on a Web page. In this embodiment, the clientprogram can be referred to or considered a “player program.” The playerprogram, in addition to carrying out the functions of the client program36, enables the retrieval and playback of video data. Ordinarily, abrowser program 38 is run on the user terminal 12 to view Web content.Browser programs typically used include NCSA Mosaic, Netscape Navigator,and Microsoft Internet Explorer. The browser program 38 allows the userto hotlink among various Web sites on the Internet.

The EMBED tag is used within HTML documents to indicate which Web pagesinclude content managed by the system. When the browser program 38receives a Web page containing an EMBED tag, a download of the filereferenced by the tag is commenced, and the file type is analyzed. Ifthe file is of a type handled by the player program 36, e.g. MPEG, thebrowser program 38 initiates the player program 36. The contents of thetag are then passed by the browser program 38 to the player program 36.

The player program 36 (FIG. 1) provides the Smart Mirroring servicesfacilitated by the MSP 32. The operation of the player program 36 isshown in detail in FIG. 3.

The player program first analyzes the EMBED tag to determine if there isan “SM” (Smart Mirror) parameter (step 60); the presence of such aparameter indicates that the embedded clip is enabled for SmartMirroring. Data associated with the “SM” parameter specifies theparticular content provider from which the desired clip originated, aswell as the group of mirror servers that particular content provideruses.

If the player program 36 determines that the EMBED tag references avideo clip or other content handled by the system (step 62), thetransfer of the embedded clip from the content provider 22 is stopped.The player program 36 then extracts access control or rating informationfrom the EMBED statement (step 64), if any exists. This ratinginformation is compared against the reference levels stored in theconfiguration file stored at the user terminal 12 (step 66). If ratinginformation does not exist for the clip, the configuration file isqueried to determine whether unrated clips, as defined below, may beplayed (step 68). Based on the foregoing information, the player program36 will authorize or decline the viewing of the desired clip.

If playback is authorized, the player program 36 attempts to find thereferenced clip on the local computer belonging to the user terminal 12(Step 70). If it exists there, it is not re-downloaded, and can beplayed directly on the computer (from the disk or from RAM) (step 72).However, the time and date of creation of the clip on the local computeris first verified against the time and date for the clip available onthe network, to determine if the stored clip is the most recent version(step 74). If it is not, the stored clip is discarded (step 76) and thedownload proceeds as follows.

If the clip does not exist on the local computer, the player creates anew URL (step 78) in the following form: “http://”, plus the IP addressof the selected Smart Mirror site stored in the configuration file, plusthe path name to mirror files (e.g. “/pub/mirror/”), plus the name ofthe content provider taken from the “SM” parameter in the EMBEDstatement, plus the filename taken from the EMBED statement. Theconstructed URL is used to retrieve the selected clip from theappropriate Smart Mirror site selected by the configuration utility 34(step 80). If more than one set of delivery sites exists for differentcontent providers, the “SM” parameter is further used by the playerprogram 36 to determine which Smart Mirror site in the configurationfile is to be used in the constructed URL (step 82). In one embodimentof the invention, site selection is performed at least partially by aredirection server. This embodiment will be described in detail belowwith reference to FIG. 4.

If the clip corresponding to the constructed URL is not found at theSmart Mirror site, or is unable to be accessed, then the downloadproceeds from the next-highest ranked Smart Mirror site in theconfiguration file (step 84), or the next-highest ranked delivery siteselected by the redirection server (see FIG. 4). If all delivery sitesfail, the download proceeds from the original content provider's site asspecified directly by the EMBED statement.

If playback is disallowed, the player prevents the clip from beingtransferred (step 88) and displays a bitmap (step 90) advising the userthat the download is not be permitted.

If the player program 36 determines that the EMBED tag references avideo clip or other content not handled by the system, the player willcheck whether the access control level set in the configuration fileallows the user to play these clips or other files which are considered“unrated” (step 92). If so, the clip is transferred from its originalcontent provider 22 by traditional means (step 94), and the playerprogram 36 displays the downloaded file (step 96). If not, the playerprevents the clip from being transferred (step 98) and displays amessage (step 100) advising the user that the download is not permitted.

Upon download, the data file representing the desired clip is storedwithin a specified data area on the local computer, usually on the harddisk, belonging to the user terminal 12 (step 102). In one embodiment,this data area can be managed on a least-recently-used basis by theplayer program 36. That is, if no room in the data area remains for anew clip, the least-recently-used (or viewed) clip or clips can bediscarded to make room (step 104).

In one embodiment of the invention, the client program 36 is capable ofsending messages to the MSP 32 (step 106) to reflect whether downloadswere successful. This message contains the Internet address of the userterminal 12, the identity of the selected server set, the Internetaddress of the site used to accomplish the download, the Internetaddresses of all sites which failed, the name of the file downloaded,and the time to download the file. This information can also be used bythe MSP 32 to track file downloads and to determine, in real time,whether there are any problems with any Smart Mirror sites.

Alternatively, the client program 36 can maintain a small local databaseof file transfer performance. Each download would then be timed.Specifically, information can be gathered on the time it takes a serverto begin sending the requested file, the stability of the data transferrate, and the error rate of the transfer. At some interval (e.g. weeklyor once every 100 downloads), a message containing the accumulated filetransfer performance information, as well as the user and serverinformation discussed above, would be sent (automatically or uponrequest) to the MSP 32 (step 106) to update the MSP's database. Thisadditional information increases the MSP's “knowledge” of networkperformance without incurring any additional testing overhead.

This data is especially valuable in ascertaining the performance ofdelivery sites, for the purpose of assessing the quality of servicepurchased from the delivery site provider, and for documenting thequality of service to content providers, to support the cost of thesystem. It is recognized, however, that much of the same information canbe obtained through new users running the configuration utility 34.

In one embodiment of the invention, information derived from thedatabase of the MSP 32 can be used to predict an improved delivery sitefor a given user without actually having to run the configurationutility to test the network between that user and a list of potentialdelivery sites. More specifically, the aggregate network performancedata contained in the MSP 32 database is analyzed in terms of theperformance differences between a given Internet IP address and a numberof different delivery sites. Based on this analysis, a correlation canbe drawn between a user's IP address and a delivery site that offersbetter data delivery performance. This correlated data is used toproduce a look-up table which can be utilized by the MSP 32 in theprocess of delivery site selection.

In practice, a redirection server is included within the MSP network. Inone embodiment, functions of the redirection server are implementedwithin and performed by the MSP 32 server. In alternative embodiments,several redirection servers may be employed at various locationsthroughout the network.

In operation, the redirection server will acquire the IP address of theuser when the user requests a file that is managed by the MSP deliverysystem. A request is made of the redirection server through an EMBEDstatement, as discussed above. The EMBED statement can explicitly referto a specific server IP address, identifying a single redirection server(e.g. the MSP 32), or can contain a script or executable program code(e.g. in JavaScript or the Java programming language) specifying aplurality of redirection servers, to which access can be attempted insequence or in a random order. The user's IP address is then determinedby the server through traditional means, as HTTP (HyperText TransportProtocol) requests typically include information on the requester'saddress. The redirection server then maps the user's IP address to anoptimum delivery site located in the look-up table and forwards thedelivery site address to the user. The user's client program 36 or theredirection server then redirects the file request so that the file isdelivered from the optimum delivery site.

An important factor in designing the look-up table derives from thelarge number of addresses on the Internet. Every computer connected tothe Internet is assigned an address. In the conventional Internetaddressing scheme, An address is comprised of a 4-byte value that, byconvention, is expressed by converting each byte into a decimal number(0-255) and separating the bytes with a period. For example, an addressfor the “www.intervu.net” server is 192.215.147.185. With thisaddressing scheme, there are over four billion possible addresses on theInternet. Given the current state of the art, a look-up table includingfour billion addresses is too large to be useful in the embodimentdescribed herein, so a way was sought to compress the table.

It has been found that the selection of an optimum delivery site canoften be correlated to the first byte of a user's IP address. Thiscorrelation is such that, after running the configuration utility 34, astatistically significant number of users having the same first-byteaddress would select the same delivery site, or another site from asmall group of delivery sites. It has been observed that these deliverysites, in comparison to uncorrelated delivery sites, provide improvedperformance for most users having the same first-byte address. Thecorrelation is significant enough that in one embodiment of theinvention, a compressed look-up table is formed comprising a list offirst-byte IP addresses numbering 0-255, and for each address, a list ofdelivery sites providing improved performance for users havingcorresponding IP addresses. In this way, one or more delivery sites aremapped to each entry in the address list.

It should be noted that in certain circumstances, some of the first-byteIP addresses in the look-up table might not be mapped to a correspondingserver. This would be the case when, for example, few users have IPaddresses corresponding to a particular entry in the table, and notenough of them have run the configuration utility 34 to generatestatistically significant or reliable results. In this case, one or moredefault servers can be specified in the database for use when a specificserver is not identified in the look-up table.

In a preferred embodiment, the look-up list is stored at a singleredirection server, e.g. the MSP 32. However, the look-up list andrelated programming could also be stored at a web page server, a contentprovider 22 server or a combination of the above.

The redirection server is accessed to select a delivery site (step 82,FIG. 3) as follows, and as described in FIG. 4. The user, via the userterminal browser, requests a file referenced on a web page by clickingon a link having an EMBED statement for that file. If the file requestis for a file managed by the MSP's delivery system, the file request isforwarded to the redirection server (e.g. the MSP 32) using conventionalHTML file request semantics, i.e. server “GET” (step 120).

The redirection server examines the incoming request and determines theuser's network address (IP address) using the “REMOTE_HOST” variablesupplied by the web server (step 122). It should be noted that theembodiment of the invention described in FIG. 4 can be accomplishedwithout special-purpose client program (such as the client program 36)installed on the user terminal 12. If no client program 36 is installed(step 124), and the user, when queried by a script or downloadedprogram, does not want to install a client program (step 126), then siteselection will be performed entirely by the redirection server.

The redirection server then analyzes the user's IP address and examinesthe list of potential delivery sites on the look-up table to determinewhat delivery site or sites are correlated with the user's IP address(step 128). The redirection server then chooses a delivery site address,if more than one address corresponds to the user's look-up table entry(step 130). If a single delivery site address is found, then an HTTPredirection response is used to deliver the file from the selecteddelivery site (step 132). According to the HTTP specification, a filerequested from a certain server can be redirected by that server toanother location without any user or client program intervention. Siteselection is then complete (step 134). To complete the transaction, theclient program requests a copy of the file from the selected deliverysite and the delivery site server retrieves the file and delivers it tothe user.

If the user wants to install the client program 36 (step 126), then theprogram will be downloaded and installed (step 136) by traditionalmeans. If the client program 36 was already installed (step 124), or ifinstallation has just completed, the file request proceeds differently,and is able to utilize both server-side and client-side processing toretrieve a file in the most efficient manner possible.

First, the redirection server analyzes the user's IP address andexamines the list of potential delivery sites on the look-up table todetermine what delivery site or sites are correlated with the user's IPaddress (step 138). In some cases, it is possible that the redirectionserver storing the look-up table will generate (step 140) and send (step142) to the user terminal 12 a small file including a sublist ofdelivery sites and rely on the client program 36 to make the finaldelivery site selection (step 144). There are a number of reasons thismay occur.

First, as previously noted, an analysis of aggregate network performancedata may indicate that a number of delivery sites (as opposed to asingle delivery site) offer improved performance to certain users havingthe same first-byte address range. This occurs, for example, where anumber of users, all having the same first-byte address or range ofaddresses within a single first-byte address, selected differentdelivery sites after running the configuration utility. In this case,the client program 36 can take the sublist downloaded by the redirectionserver and compare it to a saved list of mirror sites which had beenpreviously selected by running the configuration utility (see FIG. 3,step 54). If a match is found, the client program redirects the filerequest to the matching delivery site (step 146). The client would alsohave the option to ignore the selection make by the client program andmake a best-guess selection from among the delivery sites contained inthe look-up list, since one or more of these delivery sites may offerimproved performance over any delivery site previously selected by theconfiguration utility, especially if the configuration utility has notbeen run recently.

Second, a situation may also arise where the number of delivery sitesand IP addresses managed by the MSP has increased to a point where thelook-up table becomes too large to be practical, i.e., the redirectionserver is delayed in responding to a new file request because it is busysearching through the look-up tables on behalf of a previous filerequest. If this is the case, the task of searching through the look-uptable is split between the redirection server and the client program 36.Thus the user terminal 12 is required to do some of the processing andalso act as a router by making the final delivery site selection.

In order to accomplish this, the redirection server subdivides thelook-up table into smaller sublists with a given range of addresses.Thus, when the redirection server receives a request for a file, theserver will map the user's IP address (step 138) to the sublist with thecorresponding address range, and then generate (step 140) and download(step 142) to the user a small file containing the sublist. The clientprogram 36 then acts as a router, selecting a delivery site (step 144)from among the delivery sites in the sublist look-up table, by eithermapping the user's IP address to the proper correlated delivery siteaddress on the sublist, or by looking for a match between a deliverysite on the sublist and a delivery site on the prioritized list of sitessaved by the configuration utility 34 after previously running networkperformance tests, as described above. Once the client program hasselected a delivery site, the client program redirects the file requestto the selected delivery site (step 146). By splitting the work betweenthe redirection server and the user terminal 12, the file request can beprocessed quicker, thereby reducing the delay between the time the userrequests the file and the time when the file is received by the userterminal 12.

Although the MSP 32 redirection look-up table will be updated frequentlyin response to changes in network performance, the sublists passed downto the user are expected to be satisfactory for at least a few days.Thus, the client program 36 can reuse the list for a few days beforeacquiring a new sublist. This function can be implemented, for example,by a script embedded in the web page hosting the file request statement.The script can query the client program 36 for an expiration dateencoded in the sublist stored at the user terminal 12. The expirationdate and sublist type can be passed back to the redirection server andif necessary, the server will pass down a new sublist.

It is possible that a particular user may request a file managed by theMSP delivery system, and the system will have no knowledge of that user(i.e., no matches are found between the user's IP address and deliverysites in the look-up table). In this case, the redirection server willselect a delivery site for the user (steps 130 and 144) from a defaultlist stored at the redirection server. When the user downloads therequested file from this delivery site, he may be prompted via anembedded script or program to acquire the configuration utility filefrom the MSP 32 for the purpose of improving content delivery, or willbe temporarily assigned a server which is an approximation (e.g. has asimilar, but not identical, first-byte IP address) for improved contentdelivery. If the user acquires and runs the configuration utility, theuser terminal 12 will begin providing the MSP 32 with the results ofvarious network tests, as described above, and this information willultimately become part of the MSP database of network performance data.Thus, on the next file request from that new user, the redirectionserver will be able to map the user's IP address to a more appropriateserver based on an analysis of the additional network performance data.

By modifying the look-up table, the redirection server can also performload balancing and management with respect to file requests. If the MSP32 (or an individual controlling the MSP 32) determines in advance thatsections of the network will be down for a period of time, or if certaindelivery sites must be shut down for a period of time, the look-up tablecan be modified so that the redirection server will point users toalternative delivery sites. Thus, it is possible that on twoback-to-back requests for the same file, a user may be directed to twodifferent delivery sites.

It should be appreciated that the file comprising a sublist of thelook-up table can function as the delivery site file which is used bythe configuration utility 34 to run network tests. The sublistrepresents delivery sites which have already been screened for improvedperformance via aggregate network performance data derived from a groupof other users who have previously conducted network tests. This sublistof delivery sites can be further pared-down or prioritized by runningthe configuration utility 34 against the list and performing thesequence of network tests retained from a previous delivery site file.Once the sublist is prioritized, the configuration utility 34 saves thelist to the (encrypted) configuration file as described above.

In the following exemplary description, the Smart Mirror system utilizesthe look-up table to locate an improved delivery site from which todownload a video clip referenced on a Web page advertising banner. Whendealing with relatively unpopular content such as advertising, it isimportant to deliver advertising content to the intended customer asquickly as possible, so the potential customer does not lose interest.With respect to the content in a Web page advertising banner, the sameis true: it is desirable to be able to deliver the video to the customeras quickly as possible without having to download a substantial amountof software in advance. Therefore, as an alternative to utilizing theinvention as a premium service, a service provider can distributeadvertising banners on Web pages across the Internet. Each banner wouldreference a video clip, and all of the clips would be stored at acontent provider's server established for that purpose.

In this example, the client program 36 is referred to as a “playerprogram,” and it has the added functionality of retrieving and playingback video data as previously described. A browser 38 (such as NetscapeNavigator or Microsoft Internet Explorer) is used to view Web content atthe user terminal 12 and to communicate between the user terminal 12 andother computers on the Internet 10.

When the client selects an advertising banner displayed on a Web page,an EMBED tag encoded in the banner is examined by the browser. Thebrowser commences a download of the file referenced by the EMBED tag andthe file type is analyzed. If the file is of a type handled by theplayer program, e.g. MPEG, the browser initiates the player program bypassing the tag to the player program. The player program examines theEMBED tag for the file name of the video clip and attempts to find theclip on the local computer belonging to the user terminal. If it existsthere, it is not re-downloaded, and can be played directly on thecomputer (from the disk or from RAM). If the video clip is not on thelocal computer, the player program analyzes the EMBED tag to determineif there is an “SM” (Smart Mirror) parameter; the presence of such aparameter indicates that the embedded clip is enabled for SmartMirroring. The SM parameter further specifies the address of theredirection server, and as discussed above, the particular contentprovider from which the desired clip originated, as well as the group ofmirror servers that particular content provider uses.

If the player program recognizes a parameter specifying a redirectionserver, the player program will invoke the browser to request thereferenced ad banner file from the redirection server via conventionalHTML file request techniques. The redirection server examines theincoming request and determine the IP address of the client. Theredirection server maps the client's IP address to the look-up table andretrieve a delivery site address or a sublist. The delivery site address(or a sublist of delivery sites and IP addresses) is returned to theplayer program by the redirection server. If a sublist is returned, theplayer program selects a single delivery site from among those listed,as previously described. Once a single delivery site is determined, theplayer program creates a new URL in the following form: “http://”, plusthe IP address of the selected delivery site, plus the path name tomirror files (e.g. “/pub/mirror/”), plus the name of the contentprovider taken from the “SM” parameter in the EMBED statement, plus thefilename taken from the EMBED statement. The constructed URL is used toretrieve the selected clip from the delivery site selected from thelook-up table.

If the SM parameters in the EMBED tag do not specify a redirectionserver, or if the redirection server is unavailable and does not returna response, the player program will select an IP address from theprioritized list of Smart Mirror sites stored in the configurationutility file and substitute this address in the URL. If the playerprogram does not detect the presence of the prioritized list of smartmirror sites (for example, if the user never downloaded theconfiguration utility 34), then the player program will request thevideo using the address of the original content provider's server, asspecified directly by the EMBED statement.

In applications not specifically targeted to the delivery of advertisingcontent, the provision of download information to the MSP facilitatesthe use of the invention as a premium subscription-based service. Assuccessful downloads are tracked in a database, each user can have anassociated “account” to track charges. The user can be charged for useof the Smart Mirror system by the file, by the megabyte, by the month,or by other known means. In one embodiment, the EMBED tag associatedwith a file contains billing information, or a “price” for the file. Theinvention's tracking of download performance allows discounts or creditsto be issued if downloads are found to be unduly difficult or slow.

To ensure that files stored on Smart Mirror delivery sites are used onlyby authorized users of the invention (e.g. those users having paidaccounts), the files stored at the delivery sites can optionally be inencrypted form, and the downloading step described above can include adecryption step. Such encryption and decryption can be performed by wellknown means.

As discussed above, the clips managed by the invention can have contentrating information associated therewith. This is accomplished byproviding a “PG” parameter in the EMBED statement corresponding to theclip. In one embodiment, four characteristics are rated: nudity,sexuality, profanity, and violence. Accordingly, the PG parameter can bespecified by a four-digit argument. Each characteristic is rated on ascale of one to three. One corresponds to no filtering (i.e. all contentis allowable), two corresponds to some filtering (e.g. equal to levelstypically allowed in broadcast television), and three corresponds to themost extensive filtering (e.g. for children). The ratings levelscontained in the EMBED statement for a file are compared to the ratingsfilter levels contained in the configuration file stored at the userterminal 12 in the foregoing authorization process, and only authorizedfiles are transferred.

In view of the above, it will be appreciated that embodiments of theinvention may be employed in many different applications to permit theacquisition and analysis of performance data for networks between agiven user and content provider or delivery site. Thus, although thedescribed embodiment illustrates the system operating within the contextof the Internet, and with an Internet-type addressing scheme, it isrecognized that such a system could prove to be useful in other networkenvironments, including but not limited to corporate “intranets.”

Moreover, although the illustrative embodiments are described primarilyfor use in a video delivery system, it should be recognized that asystem according to the invention can be used to distribute variousother kinds of computer data (e.g. application programs, database filesand other business information, virtual reality files, multimedia suchas Macromedia Shockwave files, and large text files such as books) aswell. Such other types of data can be managed by the invention indifferent content provider groups as discussed in detail above; adifferent type of program (rather than the player program 36) typicallywould be invoked at the user terminal 12 to view or use other types ofdata.

It should also be noted that certain functionality described asperformed at the user terminal 12 (specifically, certain functionsperformed by the configuration utility 34, or client/player program 36)can be implemented as a standalone program, as a “plug-in” or “helperapplication” to run within a browser program, or as a Java appletdownloaded from a delivery site to run within a browser environment. Foruser terminals capable of running the Microsoft Windows operatingsystem, an environment known as Microsoft ActiveX is also useful.

While certain exemplary structures and operations have been described,the invention is not so limited, and its scope is to be determinedaccording to the claims set forth below.

1. A method of content delivery managed by a service provider on behalf of participating content providers in a distributed computer network, wherein machines make requests for participating content provider content, comprising: locating delivery sites at network locations, wherein a given delivery site supports content from multiple participating content providers; generating a table that is indexed by a set of values each corresponding to a byte of a given IP address, wherein for each such value, the table includes IP addresses identifying a subset of delivery sites, where the table is generated based on network performance data collected by the server provider; and in response to a machine at a given IP address making a request for content being managed by the service provider, using a byte of the machine's IP address as an index into the table to associate the request with an IP address of at least one of the subset of delivery sites.
 2. The method of content delivery as described in claim 1 further including modifying the table as a function of the network performance data.
 3. The method of content delivery as described in claim 2 wherein the table is modified to alter the one or more IP addresses identifying the subset of delivery sites.
 4. The method of content delivery as described in claim 3 wherein, as a result of the modification, requests for content are directed to an alternate delivery site. 